This invention relates generally to medical imaging and more particularly, to a programmable imaging system.
Medical imaging systems generally are utilized for imaging parts of patient""s bodies for physician review. Different imaging technologies, sometimes referred to in the art as modalities, may be used for imaging patient body parts. Examples of imaging modalities include computed tomography (CT), magnetic resonance (MR), ultrasound, positron emission tomography (PET), and nuclear imaging.
With respect to generating, processing, and displaying medical images, the development of medical imaging applications generally requires significant software development effort. The development is usually performed by highly skilled software practitioners since specialized software skills are needed to develop graphical user interface (GUI) based medical imaging applications. The software engineers, however, have limited domain knowledge. The clinicians who actually use the software applications typically lack the software engineering skills required for developing the applications. It would be desirable to provide an imaging system which is highly usable so that clinicians can develop imaging applications.
Known xe2x80x9cprogrammablexe2x80x9d systems enable clinicians to generate customized imaging applications. The most simple type of customization, for example, allows customization of display screens for a particular physician or other requirements. More complex customizations are required, for example, for research institutions.
The known programmable imaging systems, however, have a number of shortcomings. For example, one known programmable system does not provide the capability of creating/customizing new GUI elements. In addition, such system is not integrated into the base system, which results in visual, functional, and usability problems. Also, only an experienced programmer can add functionality to the system.
The following sets forth additional shortcomings in known programmable imaging systems. These shortcomings generally relate to script generation and execution, asynchronous execution, and review template editor functions.
Scripts typically are utilized for controlling the display and processing sequence of medical image so that a physician who reviews the image can view the image data in a desired format. For example, a particular physician may prefer a particular sequence of views be displayed when viewing a particular organ. A script can be generated to control the image display so that the desired sequence of views is generated and displayed.
Generating fully functional and usable scripts from graphical user interface (GUI) based software applications is difficult. Typically, scripts are generated by recording GUI events, such as button clicks, and replaying the events in the same application. In many situations, however, it is desirable to produce output scripts that can be used within the context of a different processing environment. In these situations, the semantics of the actions performed by the user must be captured rather than a mere sequence of GUI events.
There are many examples of applications that provide facilities for recording and playing back GUI events at various levels. One such known program records the mouse movements, button presses and keyboard clicks, and replays these events. Even small changes to the GUI, however, requires that the events be re-recorded to capture the changes.
Another known application records the GUI widget (buttons, sliders, etc.) that was activated (pressed) rather than simple mouse and keyboard actions. This program alleviates the problem with minor GUI changes, but still requires playback of the created script on the original application. That is, this program only enables recording an application and playing it back using the same application. The scripts produced are not designed for use outside of the instrumented application. Additionally, the syntax of the output scripts produced are completely predetermined and are not user configurable.
Known medical imaging systems have a client server architecture. A major advantage of this architecture is that the application process can remain attentive to the user because the application does very little processing. Most processing is handled by servers. The servers, in turn, are xe2x80x9cspecialistsxe2x80x9d at providing a particular service and may in fact be running on specialized hardware, optimized for particular tasks. A good example of this specialization is a processing server having hardware acceleration of common image processing operations. The ability to access network distributed resources is a major advantage of the client-server architecture.
With respect to task execution in a client-server architecture, the application makes a request for some service. Because the servers(s) which process the requests can reside anywhere on the local area network, the application must wait for the operation to complete before reporting the results back to the user. The amount of time the application must wait depends on many factors, including the speed of the server. To remain interactive, the application must yield, which typically is performed by returning the execution thread to the idle state so that the application can respond to other user requests. This yielding function is fundamental to a highly interactive application. When the reply from the previously queued request arrives, the application must then restore the processing context of the application to its prerequest state and present the results of the operation. This process is commonly referred to as asynchronous behavior.
Experience has shown that implementation of the request-yield-reply paradigm introduces significant programming obfuscation because single operations must be broken up into multiple execution threads, state or context information must be managed to bind the request side to the reply side, and subtle, difficult to diagnose timing related errors can creep into the code due to multiple interactive asynchronous execution threads. The resulting code also is difficult to maintain. These factors have significantly reduced the productivity of programmers in this environment.
Moreover, the asynchronous execution application code is complex and advanced computer programming skills are required to develop code in this environment. For example, a six to eight week training period is typical for an experienced software engineer in the request-yield-reply development paradigm described above. Much of this training period is spent appreciating the finer points of asynchronous software programming. Further, the complexity of asynchronous programming makes it an unsuitable approach for most end users who are not usually software engineers. For the most part, developers of client-server applications have accepted the development inefficiencies of the request-yield-reply program paradigm as a penalty for the additional flexibility and high interactivity of client-server applications.
In addition, and in an attempt to avoid some shortcomings of asynchronous operation, some approaches exist in which database functions behave synchronously. For example, in one known approach, a programmer detects abnormally long operations and takes corrective actions. The mechanism used to implement this behavior is a polling mechanism where the GUI is frozen during the wait phase, i.e., it does not implement a true yield. In medical imaging and real time control applications where response latency must be very low, this type of mechanism may not be acceptable since an operator may have to respond to an emergency situation during long transactions. A further disadvantage of this approach is that long operations cannot be cancelled during the wait period. It would be desirable to provide a system in which application interactivity is preserved even during long transactions while eliminating the chores of coding in a request-yield-reply paradigm and maintaining its benefits.
In developing medical imaging applications, a frequent activity is to construct a review template. A review template is a graphical presentation of images, curves, text and other patient information relevant to the review of medical diagnostic information. In constructing a review template, rectangular cells typically are constructed, the arrangement of the cells on the screen is selected, and the specification of attributes for those cells is generated. Cells can contain images, curves, text, and other information relevant to the diagnostic process.
For many physicians who review patient information, the presentation and format of the information is very important. Therefore, many physicians demand personalized review templates to suit their personalized diagnostic needs. To enable end user customization of review templates, an imaging system must provide an easy method for constructing or modifying review templates. In addition, the review template editors preferably are optimized for particular tasks.
One known system for constructing a review template includes the use of graphical review template editors which provide a point and click interface for creating the templates. The graphical editor has been found to be an easy way for the end user to construct review templates.
One shortcoming of known review template editors, however, is that such systems require the user to correct for cell overlap. Specifically, the cells are tiled and never overlap because overlap would occlude important diagnostic information. The user therefore must painstakingly and meticulously position cells using the mouse or a property editor. To aid in this task, some review template editors include tools such as a zoom mode to enable more accurate alignment. Other known systems provide tiling post-processors which pack the cells in a minimal geometric configuration. For medical imaging review template construction, these tools are either too time consuming in execution or lack flexibility because they do too much for the user, as in the case of the tiling post-processors. It would be desirable to provide an automatic overlap detection and correction algorithm which enables increased ease of use by accelerating manual cell alignment tasks.
The above described shortcomings associated with known programmable systems preferably would be overcome in a programmable system which is extremely user friendly so that clinicians can relatively easily and quickly develop imaging applications. In addition, and with respect to scripts, such scripts preferably could be used in many different environments so that regardless of the environment, images and data can be displayed for physician review in accordance with that physician""s desires without significant additional effort and expense. Generation of such scripts also preferably would be simplified and interactive. Further, and as described above, it would be desirable to provide a system in which application interactivity is preserved even during long transactions while eliminating the chores of coding in a request-yield-reply paradigm and maintaining its benefits. Also, and for review template generation, it would be desirable to provide an automatic overlap detection and correction algorithm which enables increased ease of use by accelerating manual cell alignment tasks.
These and other objects may be attained in a programmable, medical imaging system which incorporates algorithms for enhancing the usability of the system for clinicians. With respect to programmability, and in one aspect, the present invention relates to a programmable system which includes a learn mode usable for script generation. In the learn mode, a user can rehearse a sequence of actions and save those actions to be replayed later. The learn mode provides an intuitive starting point for the definition of a new user protocol because it allows the user to develop novel functionality with no programming effort.
More specifically, and with respect to the learn mode, the system includes an initialization/instrumentation subsystem which includes a configuration file, a table loader and an auto installer. In operation, the table loader reads in the configuration file and uses the information read from the configuration file to initialize a master table. Also, the auto installer uses the xe2x80x9cWidget namexe2x80x9d stored in master table to find the associated widget from the graphical user interface (GUI) application, and stores the widget id back in the master table.
A user, working at the system GUI, inputs a series of events which are recorded by the GUI event handler system. A code generator outputs a script command corresponding to each specified GUI action. Also, a code compression system extracts the output variables from the current command and the previous command, and compares the output variables to the ones and zeros in the compression code. If all the unmasked object name sub-expressions are the same, the output is considered to be a replacement of the previous output. The system tracks the previous output and deletes it if the new output is considered a replacement. The output from the code compression system generally is referred to as an output script.
The output scripts generated using the above described system are easily and readily transferable to other processing environments. In addition, such system is relatively easy to use as compared to known programmable systems, and is extremely user friendly. Moreover, the system interprets the sequence of user actions (e.g., key clicks and mouse movements) into output commands in a manner that captures the intent of the operations, rather than simply recording the actions themselves. For example, in order to add two images, the GUI may require the user to perform a series of actions such as selecting the images to add, selecting the add operation, applying the selected operation, and so on. With the present system, the output represents commands to add the images as the user intends rather than the process of selecting individual images.
In another aspect, the present invention is directed to an algorithm which provides a non-blocking, synchronous interface to an underlying asynchronous architecture. Generally, the algorithm decouples the client-server portion of the application from the synchronous development environment. Using this algorithm, a programmer can develop a non-blocking, highly interactive, client-server application without having to resort to asynchronous programming techniques.
The resulting code is synchronous, highly readable, compact and can be developed by a practitioner not familiar with programming in a client-server architecture. Further, this algorithm can be practiced on operating systems which have or do not have intrinsic support of multiple execution threads.
In yet another aspect, the present invention is directed to an overlap detection and correction algorithm which, in one form is integrated into a review template editor for creating review templates. The overlap detection and correction algorithm, in one embodiment, is a one or two boundary rectangular cell overlap detection and correction algorithm. The algorithm is non-packing so that it accurately carries out the intention of the user""s alignment actions, and provides the important advantage of accelerating cell alignment tasks.
The above described programmable system is extremely user friendly and it is believed that clinicians can relatively easily and quickly develop imaging applications using the system. Also, scripts generated using the system can be easily transported for use in many different environments so that regardless of the environment, images and data can be displayed for physician review in accordance with that physician""s desires without significant additional effort and expense. In addition, although a client-server architecture is utilized, system interactivity is preserved even during long transactions while eliminating the chores of coding in a request-yield-reply paradigm. Further, and with respect to review template generation, the automatic overlap detection and correction enables increased ease of use by accelerating manual cell alignment tasks.